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CLAIMS 

We Claim: 

1 . A networked computing system comprising: 

a) a network resource that is to be maintained; 

b) a lock data area indicating an ownership status of the network resource; 

c) a lock server process for maintaining the lock data area ; 

d) a plurality of clients that are to perform maintenance on the network resource, a 
client being operative to: 

i) send a command to the lock server process to modify the lock data area 
to indicate ownership of the network resource by the client; 

ii) receive a response from the lock server process indicating whether or 
not ownership of the network resource by the client is indicated by the 
lock data area; 

iii) perform maintenance on the network resource only if ownership of the 
network resource is indicated by the lock data area. 

2. The system of claim 1 wherein, if the response indicates that ownership of the 
network resource by the client is not indicated by the lock data area, the client is 
operative to: 

i) set a retry interval timer; and 

ii) upon expiry of the retry interval timer, send a further coromand to the 
lock server process to modify the lock data area to indicate ownership of 
the network resource by the client. 

3. The system of claim 2 wherein, after at least two unsuccessful attempts to modify 
the lock data area to indicate ownership of the network resource by the client, Ihe client is 
operative to: 

i) determine, from lock owner viability data received from the lock server 
process, whether or not a current lock owner is viable; and 
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ii) if the current lock owner is not viable, send a command that is 
configured to establish the cUent as the lock owner notwithstanding that 
the client is not the current lock owner. 

4. The system of claim 1 wherein the command includes client viability data, the 
client being operative to, upon successfully modifying the lock data area to indicate 
ovraership of the network resource by the client: 

i) set a reacquire interval timer; and 

ii) send updated client viability data to the lock server process if 
maintenance being performed by the client has not been completed when the reacquire 
interval timer expires. 

5. The system of claim 1 wherein each of the plurality of clients has a unique and 
non-null lock owner ID. 

6. The system of claim 1 wherein the lock data area includes lock owner data, lock 
viability data, and retain interval data, and the command to the lock server process to 
modify the lock data area includes a set value, a test value, a viability value, and a retain 
interval value. 

7. The system of claim 6 wherein the lock data area contains null data values when 
the network resource is not owned by any client. 

8. The system of claim 6 wherein the lock server process is operative to: 
compare the test value in the command with a lock owner value in the lock data 

area; and 

write the set value into the lock owner value if said comparison shows that the test 
value is equal to the lock owner value. 

9. The system of claim 8 wherein the lock server process is operative to send a 
response to the client after conducting any updates in the lock data area. 
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10. The system of claim 9 wherein the response includes lock owner data, lock 
viability data, and retain interval data stored in the network resource. 

1 1 . The system of claim 8 wherein the client constructs the command with a set 
value equal to the client's lock owner ID and a null test value, imless the client has 
determined that the current lock owner is no longer viable. 

12. The system of claim 8 wherein the client is operative to force the lock data area to 
indicate ownership of the network resource, the network resource nominally being owned 
by a second client, by sending a command that includes a test value equal to an identity 
of the second cUent and a set value equal to an identity of the forcing client. 

1 3 . The system of claim 3 wherein the step of determining lock owner viability 
performed by the client comprises: 

comparing lock owner data and lock viability data received in two consecutive 
responses from the lock server process. 

14. The system of claim 13 wherein Ae client is operative to consider the current lock 
owner viable if the lock owner data or lock viability data received in two consecutive 
responses from the lock server process differ, and to otherwise consider the current lock 
owner non-viable. 

15. A client process for maintaining a network resource, authorization to maintain the 
network resource being indicated by the contents of a lock data area stored on the 
network resource, the client process being configured to: 

send a first request to modify the lock data area to indicate that the cHent process 
is authorized to maintain the network resource; 

receive a first response indicating whether or not the client process has 
successfully modified the lock data area to indicate that the client process is authorized to 
maintain the network resource; and 
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send maintenance commands to the network resource only if the first response 
indicates successful modification of the lock data area. 

16. The client process of claim 15 wherein the client process is fiirther configured to: 
set a first retry interval timer if the first response indicates that the client process 

has not successfully modified the lock data area to indicate that the cUent process is 
authorized to maintain the network resource; 

after the first retry interval timer expires, send a second request to modify the lock 
data area to indicate that the client process is authorized to maintain the network 
resource; 

receive a second response indicating whether or not the client process has 
successfully modified the lock data area to indicate that the client process is authorized to 
maintain the network resource; and 

send maintenance commands to the network resource only if the second response 
indicates successful modification of the lock data area. 

17. The client process of claim 1 5 wherein the first response includes first viability 
data and the second response includes second viability data, the client process being 
configured to: 

compare the first viability data with the second viability data; 

based on the comparison, either set a second retry interval timer or send a third 
request to modify the lock data area, the third request being configured to ensxire that the 
lock data area will be modified to indicate that the client process is autiiorized to maintain 
the network resource; 

receive a third response indicating whether or not the client process has 
successfully modified the lock data area to indicate that the client process is authorized to 
maintain the network resource; and 

send maintenance commands to the network resource only if the third response 
indicates successful modification of the lock data area, 

18. The client process of claim 1 5 wherein the client process is further operative to: 
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set a reacquire interval timer if the client process receives a response indicating 
successful modification of the lock data area to indicate that the client process is 
authorized to maintain the network resource; 

provide viability data to be stored in the lock data area; 

on every expiry of the reacquire interval timer, restart the reacquire interval timer 
and send a request to modify the lock data area with new viability data to indicate that the 
client process continues to viably hold the network resource, and 

upon completion of the maintenance commands by the network resource, cancel 
the reacquke interval timer and send a new request to modify the lock data area vdth null 
values to indicate that the network resource is no longer owned by any client process. 

1 9. The client process of claim 1 7 wherein the client process is further operative to: 
abort the intended transmission of maintenance commands to the network 

resource with an appropriate error indication if the first, second, and third responses 
indicate that the client process has not successfully modified the lock data area to indicate 
that the client process is authorized to maintain the network resource. 

20. The client process of claim 16 wherein the duration of the retry interval timer is at 
least twice the duration of retain interval data returned in a response sent by tiie lock 
server process. 

21 . A lock server process for use in regulating maintenance activities performed on a 
network resource, comprising: 

a lock data area for indicating an ownership status of the network resource, the 
lock data area including lock owner data; and 

a lock server routine, the lock server routine being operative to receive an 
instruction to modify the lock owner data, the insfruction including a set value and a test 
value, the lock server routine being operative to: 

compare the test value against the lock owner data; and 

replace the lock owner data with the set value if the test value is the same as the 
lock owner data. 
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22. The lock server process of claim 21 wherein the lock data area fijrther includes 
viability data and the instruction further includes a viability value, the lock server routine 
in use being operative to replace the viability data in the lock data area with the viability 
value in the instruction if the test value is the same as the lock owner data. 

23. The lock server process of claim 21 wherein the lock data area further includes 
retain interval data and the instruction further includes a retain interval value, the lock 
server routine in use being operative to replace the retain interval data in the lock data 
area with the retain interval value in the instruction if the test value is the same as tiie 
lock owner data. 

24. The lock server process of claim 22 wherein the lock data area further includes 
retain interval data and the instruction further includes a retain interval value, the lock 
server routine in use being operative to replace the retain interval data in the lock data 
area with the retain interval value in the instruction if the test value is the same as the 
lock owner data. 

25. The lock server process of claim 21 wherein the lock server routine is operative to 
respond to the instruction with the lock owner data after conducting any updates in the 
lock data area. 

26. The lock server process of claim 22 wherein tiie lock server routine is operative to 
respond to the instruction with the lock owner data and the viability data after conducting 
any updates in the lock data area. 

27. The lock server process of claim 23 wherein the lock server routine is operative to 
respond to the instruction with the lock owner data and the retain interval data after 
conducting any updates in the lock data area. 
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28. The lock server process of claim 24 wherein the lock server routine is operative to 
respond to the instruction with the lock owner data, the viability data and the retain 
interval data after conducting any updates in the lock data area. 

29. The lock server process of claim 21 wherein the lock server routine is operative 
to modify the lock data area with null values to indicate that the network resource is not 
owned by any client process, whenever the network resource is powered on or is reset via 
an operator command, 

30. The lock server process of claim 21 wherein the lock data area is organized as a 
plurality of locks for control of concurrent maintenance operations performed on the 
network resource. 
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